7. 쿠버네티스 개요6
3.7 쿠버네티스의 파드와 CRI 컨테이너 런타임
3.7.1 kubelet으로 파드 관리
노드 컴포넌트란?
각 노드에는 다수의 노드 컴포넌트라고 하는 컴포넌트 그룹이 구동되고, 해당 노드에서 컨테이너 그룹의 실행 관리, 레지스트리에서 이미지 가져오기 및 관리, 네트워크 관리 등을 실행함
쿠버네티스 클러스터 구성:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌─────────────────────────────────────────────┐
│ Control Plane │
│ ┌─────────────────────────────────────┐ │
│ │ kube-apiserver (API 요청 처리) │ │
│ │ kube-scheduler (파드 배치 결정) │ │
│ │ kube-controller (상태 유지 관리) │ │
│ │ etcd (클러스터 상태 저장)│ │
│ └─────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
│
┌───────────┼───────────┐
↓ ↓ ↓
┌───────────┐ ┌───────────┐ ┌───────────┐
│ Node 1 │ │ Node 2 │ │ Node 3 │
│ ┌───────┐ │ │ ┌───────┐ │ │ ┌───────┐ │
│ │kubelet│ │ │ │kubelet│ │ │ │kubelet│ │
│ │kube- │ │ │ │kube- │ │ │ │kube- │ │
│ │proxy │ │ │ │proxy │ │ │ │proxy │ │
│ │CRI │ │ │ │CRI │ │ │ │CRI │ │
│ │런타임 │ │ │ │런타임 │ │ │ │런타임 │ │
│ └───────┘ │ │ └───────┘ │ │ └───────┘ │
│ [Pods] │ │ [Pods] │ │ [Pods] │
└───────────┘ └───────────┘ └───────────┘
파드 스케줄링 과정:
디플로이먼트를 작성해서 쿠버네티스에 애플리케이션 배포를 지시하면 쿠버네티스의 컨트롤 플레인에 포함된 스케줄러가 애플리케이션을 구성하는 파드를 어떤 노드에서 실행할지 결정함
파드 배포 흐름:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[사용자]
│
│ kubectl apply -f deployment.yaml
↓
[kube-apiserver]
│
│ Deployment 리소스 저장
↓
[kube-controller-manager]
│
│ ReplicaSet 생성 → Pod 객체 생성
↓
[kube-scheduler]
│
│ 어떤 노드에 배치할지 결정
│ (리소스, 제약조건, 어피니티 등 고려)
↓
[kubelet] (선택된 노드)
│
│ API 서버에서 파드 사양 수신
│ CRI 런타임에 파드 생성 지시
↓
[CRI 런타임]
│
│ 이미지 풀, 컨테이너 생성, 네트워크 설정
↓
[Pod 실행 완료]
kubelet의 역할:
각 노드에서는 kubelet 노드 컴포넌트가 해당 노드의 파드 작성과 관리를 담당함. kubelet은 노드에 스케줄링된 파드를 대상으로 사용자가 설정한 파드 사양을 컨트롤 플레인 API 서버(kube-apiserver)에서 받아서 파드가 설정한 대로 노드에서 구동되도록 관리함
kubelet 역할 상세:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[kubelet]
│
├─ 파드 라이프사이클 관리
│ ├─ API 서버와 통신하여 파드 사양 수신
│ ├─ 파드 상태를 API 서버에 보고
│ └─ 파드 생성/삭제/업데이트 조율
│
├─ 컨테이너 상태 모니터링
│ ├─ liveness probe (생존 확인)
│ ├─ readiness probe (준비 상태 확인)
│ └─ startup probe (시작 확인)
│
├─ 리소스 관리
│ ├─ CPU/메모리 제한 적용
│ └─ 볼륨 마운트 처리
│
└─ CRI 런타임과 통신
└─ 실제 컨테이너 작업은 CRI 런타임에 위임
kubelet이 직접 하지 않는 작업:
파드를 구성하는 각 컨테이너 이미지는 레지스트리에서 노드로 풀로 가져오고, 이미지를 사용해 컨테이너 실행 환경을 노드에 작성하여 애플리케이션이 실행됨. 하지만 이때 실제로 다음과 같은 구체적인 파드 조작을 담당하는 작업은 kubelet의 역할이 아님:
kubelet vs CRI 런타임 역할 분담:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[kubelet이 하는 일]
│
├─ "이 파드를 만들어라" 지시
├─ 파드 상태 모니터링
├─ API 서버와 통신
└─ 전체 조율 (오케스트레이션)
[CRI 런타임이 하는 일] (kubelet이 위임)
│
├─ 레지스트리에서 이미지 가져오기 (pull)
├─ 이미지로 컨테이너 실행 환경 작성
├─ 컨테이너 그룹을 파드로 묶기
└─ 파드에 네트워크 인터페이스 설정
이런 작업은 컨테이너 런타임 중에서도 특히 CRI 런타임에 해당하는 컨테이너 런타임이 담당함
용어 정리
- 노드 컴포넌트: 각 노드에서 실행되는 소프트웨어 그룹. kubelet, kube-proxy, CRI 런타임 등이 포함됨
- kubelet: 노드의 파드 라이프사이클을 관리하는 에이전트. API 서버에서 파드 사양을 받아 CRI 런타임에 작업을 위임함
- Control Plane: 클러스터의 전체 상태를 관리하는 컴포넌트 그룹. kube-apiserver, kube-scheduler, kube-controller-manager, etcd로 구성
- kube-scheduler: 새로 생성된 파드를 어떤 노드에 배치할지 결정하는 컴포넌트. 리소스, 제약조건, 어피니티 등을 고려
- liveness probe: 컨테이너가 정상 동작 중인지 확인하는 헬스체크. 실패 시 컨테이너 재시작
- readiness probe: 컨테이너가 트래픽을 받을 준비가 되었는지 확인. 실패 시 서비스 엔드포인트에서 제외
3.7.2 CRI 런타임
CRI 런타임이란?
CRI 런타임은 각 노드에서 실행되는 소프트웨어. 쿠버네티스, 특히 kubelet에서 파드 조작 관련 지시를 받아서 그에 따라 이미지를 레지스트리에서 가져오거나, 컨테이너 그룹을 파드로 작성하는 등의 작업을 수행함
CRI (Container Runtime Interface) 개념:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[kubelet]
│
│ CRI (gRPC API)
│ ├─ RuntimeService: 파드/컨테이너 관리
│ └─ ImageService: 이미지 관리
↓
┌─────────────────────────────────────┐
│ CRI 런타임 선택 │
│ ┌───────────┐ ┌───────────┐ │
│ │containerd │ │ CRI-O │ ... │
│ │(Docker 기반)│ │(Red Hat) │ │
│ └───────────┘ └───────────┘ │
└─────────────────────────────────────┘
│
│ OCI Runtime Spec
↓
┌─────────────────────────────────────┐
│ OCI 런타임 │
│ ┌───────┐ ┌───────┐ ┌────────┐ │
│ │ runc │ │ crun │ │ kata │ │
│ │(표준) │ │(경량) │ │(VM기반)│ │
│ └───────┘ └───────┘ └────────┘ │
└─────────────────────────────────────┘
CRI API 규격:
kubelet에서 CRI 런타임을 호출하는 API 규격은 쿠버네티스의 Container Runtime Interface로 정의하고, 각 CRI 런타임은 gRPC API를 제공함
CRI API 주요 기능:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[RuntimeService] 파드/컨테이너 라이프사이클
│
├─ RunPodSandbox() : 파드 샌드박스 생성
├─ StopPodSandbox() : 파드 샌드박스 중지
├─ RemovePodSandbox() : 파드 샌드박스 삭제
│
├─ CreateContainer() : 컨테이너 생성
├─ StartContainer() : 컨테이너 시작
├─ StopContainer() : 컨테이너 중지
├─ RemoveContainer() : 컨테이너 삭제
│
└─ ExecSync() : 컨테이너 내 명령 실행
Exec() : 스트리밍 명령 실행
[ImageService] 이미지 관리
│
├─ PullImage() : 이미지 다운로드
├─ ListImages() : 이미지 목록 조회
├─ ImageStatus() : 이미지 상태 확인
└─ RemoveImage() : 이미지 삭제
주요 CRI 런타임 구현체:
CRI 런타임 비교:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[containerd]
│
├─ 출처: CNCF 프로젝트 (Docker에서 분리)
├─ 특징: 가장 널리 사용됨
├─ 사용처: Docker Desktop, GKE, EKS, AKS
└─ OCI 런타임: runc (기본)
[CRI-O]
│
├─ 출처: Red Hat 주도 개발
├─ 특징: 쿠버네티스 전용으로 설계 (경량)
├─ 사용처: OpenShift, Fedora CoreOS
└─ OCI 런타임: runc, crun
[Docker Engine] (v1.24 이전)
│
├─ 출처: Docker Inc.
├─ 특징: dockershim을 통해 CRI 지원 (제거됨)
├─ 현재: containerd를 직접 사용 권장
└─ 참고: Kubernetes 1.24부터 dockershim 제거
OCI 런타임과의 관계:
CRI 런타임은 도커와 마찬가지로 OCI 런타임을 사용해 각 컨테이너를 노드에 작성하고, 공통의 네트워크 인터페이스를 제공해서 파드로 작동하도록 컨테이너 그룹을 묶음
CRI 런타임 내부 동작:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[kubelet: "파드 생성해줘"]
│
↓
[CRI 런타임 (containerd)]
│
├─ 1. 이미지 풀 (레지스트리에서 다운로드)
│ registry.io/app:v1 → 로컬 저장
│
├─ 2. 파드 샌드박스 생성
│ ├─ pause 컨테이너 생성 (네트워크 네임스페이스 유지)
│ └─ CNI 플러그인 호출 → IP 주소 할당
│
├─ 3. 앱 컨테이너 생성 (OCI 런타임 사용)
│ ├─ OCI 런타임 (runc) 호출
│ ├─ 컨테이너 파일시스템 준비
│ ├─ 네임스페이스 설정 (파드 샌드박스와 공유)
│ └─ 프로세스 시작
│
└─ 4. 컨테이너 상태 관리
└─ 실행 상태 모니터링 및 보고
이미지와 레지스트리 상호 운용성:
컨테이너를 배포하는 쿠버네티스 사용자 관점에서는 도커와 쿠버네티스는 사용 가능한 이미지와 레지스트리가 동일함. 도커로 빌드한 이미지를 그대로 레지스트리를 경유해서 쿠버네티스에 배포하고 실행할 수 있음
이미지 상호 운용성:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[개발 환경] [운영 환경]
│ │
│ docker build │ kubectl apply
↓ ↓
┌─────────┐ ┌─────────────┐
│ Docker │ │ Kubernetes │
│ Engine │ │ (containerd)│
└────┬────┘ └──────┬──────┘
│ │
│ docker push │ image pull
↓ ↓
┌──────────────────────────────────────────┐
│ Container Registry │
│ ┌────────────────────────────────────┐ │
│ │ OCI Image Format (표준 규격) │ │
│ │ ├─ Docker Hub │ │
│ │ ├─ Google Container Registry │ │
│ │ ├─ Amazon ECR │ │
│ │ └─ Harbor, Quay 등 │ │
│ └────────────────────────────────────┘ │
└──────────────────────────────────────────┘
이런 상호 운용성은 이미지와 레지스트리가
OCI (Open Container Initiative) 표준 규격을 따르기 때문에 가능
용어 정리
- CRI (Container Runtime Interface): kubelet과 CRI 런타임 간 통신 규격. gRPC API로 정의되어 있으며, RuntimeService와 ImageService로 구성
- CRI 런타임: CRI를 구현한 컨테이너 런타임. containerd와 CRI-O가 대표적
- containerd: CNCF 프로젝트로 Docker에서 분리된 CRI 런타임. GKE, EKS, AKS에서 기본 사용
- CRI-O: Red Hat 주도로 개발된 쿠버네티스 전용 경량 CRI 런타임. OpenShift에서 사용
- gRPC: Google이 개발한 고성능 원격 프로시저 호출(RPC) 프레임워크. CRI API 통신에 사용
- 파드 샌드박스: 파드의 네트워크 네임스페이스를 유지하는 컨테이너. pause 컨테이너라고도 함
- OCI 런타임: 실제 컨테이너를 생성하고 실행하는 저수준 런타임. runc, crun 등
3.7.3 CNI 플러그인
CNI (Container Network Interface)란?
쿠버네티스에서는 각 파드에 IP 주소를 부여해 서로 IP 주소로 통신할 수 있음. 파드 작성은 CRI 런타임이 담당하지만, 파드에 IP 주소를 할당하고 네트워크 인터페이스를 파드에 부여하는 구체적인 작업은 CRI 런타임의 역할이 아님. 이런 작업은 CNI 플러그인이 담당함
CNI 플러그인 역할:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[CRI 런타임]
│
│ "파드에 네트워크 설정해줘"
│ (CNI 표준 형식으로 정보 전달)
↓
[CNI 플러그인]
│
├─ 파드에 가상 네트워크 인터페이스 (veth) 생성
├─ IP 주소 할당 (IPAM: IP Address Management)
├─ 라우팅 테이블 설정
└─ 파드 간 통신 경로 구성
│
↓
[결과]
파드가 고유 IP 주소를 가지고
다른 파드와 통신 가능
CNI 동작 방식:
파드 네트워크 생성 과정:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 파드 샌드박스 생성 시 CRI 런타임이 CNI 호출
[CRI 런타임] → [CNI 플러그인]
│
│ CNI_COMMAND=ADD
│ CNI_CONTAINERID=abc123
│ CNI_NETNS=/var/run/netns/abc123
│ CNI_IFNAME=eth0
↓
2. CNI 플러그인이 네트워크 설정
[CNI 플러그인]
│
├─ veth 페어 생성
│ ├─ 한쪽: 파드 네임스페이스 (eth0)
│ └─ 다른쪽: 호스트 네임스페이스 (vethXXX)
│
├─ IP 주소 할당 (예: 10.244.1.15/24)
│
└─ 라우팅 규칙 설정
└─ 다른 노드의 파드로 가는 경로 설정
│
↓
3. 결과 반환
[CNI 플러그인] → [CRI 런타임]
│
│ {
│ "cniVersion": "1.0.0",
│ "ips": [{"address": "10.244.1.15/24"}],
│ "routes": [{"dst": "0.0.0.0/0"}]
│ }
↓
4. 파드 통신 가능
[Pod A: 10.244.1.15] ←→ [Pod B: 10.244.2.20]
Node 1 Node 2
주요 CNI 플러그인:
쿠버네티스에서 사용하는 CNI 플러그인 구현 방식은 다양함
CNI 플러그인 비교:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Flannel]
│
├─ 개발: CoreOS (현재 CNCF 산하)
├─ 특징: 간단하고 설정이 쉬움
├─ 통신 방식:
│ ├─ VXLAN (기본): 오버레이 네트워크
│ ├─ host-gw: 호스트 라우팅 (같은 서브넷)
│ └─ UDP: 레거시 방식
└─ 적합: 소규모~중규모 클러스터, 학습용
[Calico]
│
├─ 개발: Tigera
├─ 특징: 고성능, 네트워크 정책 지원
├─ 통신 방식:
│ ├─ BGP: 라우팅 프로토콜 사용 (오버레이 없음)
│ ├─ VXLAN: 오버레이 네트워크
│ └─ IP-in-IP: 터널링
├─ 추가 기능:
│ ├─ NetworkPolicy 지원
│ └─ 트래픽 제어 및 보안 정책
└─ 적합: 프로덕션 환경, 보안 중시
[Cilium]
│
├─ 개발: Isovalent
├─ 특징: eBPF 기반 고성능
├─ 통신 방식:
│ ├─ eBPF: 커널 레벨 패킷 처리
│ └─ VXLAN/Geneve: 오버레이 옵션
├─ 추가 기능:
│ ├─ L7 네트워크 정책 (HTTP, gRPC)
│ ├─ 서비스 메시 통합
│ └─ 관측성 (Hubble)
└─ 적합: 대규모 클러스터, 마이크로서비스
[Weave Net]
│
├─ 개발: Weaveworks
├─ 특징: 설치 간편, 암호화 지원
├─ 통신 방식:
│ └─ 자체 오버레이 프로토콜
└─ 적합: 빠른 구축, 멀티클라우드
CNI 플러그인 선택 기준:
CNI 플러그인 선택 가이드:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[학습/테스트 환경]
└─ Flannel (간단, 기본 제공)
[프로덕션 - 일반]
└─ Calico (안정적, 네트워크 정책)
[프로덕션 - 고성능]
└─ Cilium (eBPF, 최신 기술)
[클라우드 환경]
├─ AWS: Amazon VPC CNI
├─ GCP: Google Cloud CNI
└─ Azure: Azure CNI
[온프레미스/베어메탈]
└─ Calico 또는 Cilium
CRI 런타임은 파드를 작성할 때, CNI 플러그인에 파드 관련 정보를 CNI 표준으로 정해진 형식으로 제공하여 실행함으로써 파드에 통신 기능을 부여함
용어 정리
- CNI (Container Network Interface): 컨테이너 네트워크 설정을 위한 표준 인터페이스. CRI 런타임이 CNI 플러그인을 호출하여 파드 네트워크를 구성
- CNI 플러그인: CNI 규격을 구현한 네트워크 플러그인. Flannel, Calico, Cilium 등이 대표적
- veth 페어: 가상 이더넷 장치 쌍. 한쪽은 파드 네임스페이스, 다른쪽은 호스트 네임스페이스에 위치하여 파드와 호스트를 연결
- IPAM (IP Address Management): IP 주소 할당을 관리하는 기능. CNI 플러그인의 일부로 파드에 IP를 부여
- Flannel: 간단하고 설정이 쉬운 CNI 플러그인. VXLAN 오버레이 네트워크 사용
- Calico: BGP 기반 고성능 CNI 플러그인. NetworkPolicy 지원으로 보안 정책 적용 가능
- Cilium: eBPF 기반의 고성능 CNI 플러그인. L7 네트워크 정책과 서비스 메시 기능 제공
- eBPF: 리눅스 커널에서 프로그램을 실행할 수 있는 기술. 커널 수정 없이 네트워크 패킷 처리 가능
3.7.4 kube-proxy
kube-proxy란?
kube-proxy는 서비스 기능을 제공하도록 각 노드에서 통신을 관리함. 각 kube-proxy는 API 서버를 통해 서비스를 향한 통신이 어떤 파드의 IP 주소에 도착해야 하는지를 파악함
kube-proxy 역할:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Service: nginx-service]
ClusterIP: 10.96.100.50
Endpoints:
├─ Pod1: 10.244.1.10:80
├─ Pod2: 10.244.2.20:80
└─ Pod3: 10.244.3.30:80
[kube-proxy의 역할]
│
├─ API 서버 감시 (watch)
│ └─ Service, Endpoints 변경 감지
│
├─ 라우팅 규칙 생성
│ └─ 10.96.100.50:80 → Pod IP들로 분산
│
└─ 로드밸런싱
└─ 라운드로빈으로 파드 선택
서비스 트래픽 흐름:
노드에서 동작 중인 파드에서 어떤 특정 서비스와 통신이 발생하면, 해당 노드에서 통신에 대응하는 파드로 전송함
서비스 통신 흐름 (kube-proxy):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Client Pod]
│
│ curl http://nginx-service:80
│ (ClusterIP: 10.96.100.50)
↓
[Node의 네트워크 스택]
│
│ 목적지: 10.96.100.50:80
↓
[kube-proxy 규칙 (iptables/IPVS)]
│
│ DNAT (Destination NAT)
│ 10.96.100.50:80 → 10.244.2.20:80
│ (로드밸런싱으로 파드 선택)
↓
[실제 Pod로 전달]
│
│ 목적지: 10.244.2.20:80
↓
[nginx Pod]
응답 반환
kube-proxy 모드:
리눅스 노드라면 kube-proxy는 이런 통신 전송을 iptables 또는 ipvs 기능을 사용해서 구현함
kube-proxy 구현 모드:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[iptables 모드] (기본값)
│
├─ 동작: 리눅스 iptables 규칙 사용
├─ 장점:
│ ├─ 안정적, 널리 검증됨
│ └─ 대부분의 리눅스에서 지원
├─ 단점:
│ ├─ 규칙이 많아지면 성능 저하
│ └─ 서비스/엔드포인트 수에 비례해 규칙 증가
└─ 적합: 소규모~중규모 클러스터
[IPVS 모드] (고성능)
│
├─ 동작: 리눅스 IPVS (IP Virtual Server) 사용
├─ 장점:
│ ├─ 해시 테이블 기반으로 O(1) 조회
│ ├─ 대규모 서비스에도 성능 유지
│ └─ 다양한 로드밸런싱 알고리즘 지원
│ (rr, lc, dh, sh, sed, nq)
├─ 단점:
│ └─ IPVS 커널 모듈 필요
└─ 적합: 대규모 클러스터, 고성능 요구
[userspace 모드] (레거시)
│
├─ 동작: kube-proxy 프로세스가 직접 프록시
├─ 단점: 성능 낮음 (커널-유저 전환 오버헤드)
└─ 현재: 거의 사용되지 않음
iptables vs IPVS 성능 비교:
성능 비교 (서비스 수 증가 시):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
서비스 수 iptables 규칙 IPVS 성능
─────────────────────────────────────
100개 ~800 규칙 O(1) 유지
1,000개 ~8,000 규칙 O(1) 유지
10,000개 ~80,000 규칙 O(1) 유지
(성능 저하) (성능 유지)
IPVS 로드밸런싱 알고리즘:
├─ rr : Round Robin (순차)
├─ lc : Least Connection (최소 연결)
├─ dh : Destination Hashing
├─ sh : Source Hashing
├─ sed : Shortest Expected Delay
└─ nq : Never Queue
용어 정리
- kube-proxy: 각 노드에서 서비스 트래픽을 적절한 파드로 라우팅하는 컴포넌트. 서비스의 ClusterIP를 실제 파드 IP로 변환
- iptables 모드: kube-proxy의 기본 모드. 리눅스 iptables 규칙으로 서비스 라우팅 처리. 규칙이 많아지면 성능 저하
- IPVS 모드: 고성능 kube-proxy 모드. 해시 테이블 기반으로 O(1) 조회 성능 제공. 대규모 클러스터에 적합
- DNAT (Destination NAT): 목적지 IP 주소를 변환하는 기술. 서비스 ClusterIP를 실제 파드 IP로 변환할 때 사용
- 라운드로빈(Round Robin): 요청을 순차적으로 각 파드에 분배하는 로드밸런싱 방식
3.7.5 노드 컴포넌트의 관계
컴포넌트 간 상호작용:
노드 컴포넌트 관계도:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Control Plane]
│
│ API 호출
↓
┌─────────────────────────────────────────────────────┐
│ Node │
│ │
│ ┌─────────────────────────────────────────────┐ │
│ │ kubelet │ │
│ │ ├─ 파드 라이프사이클 관리 │ │
│ │ ├─ API 서버와 통신 │ │
│ │ └─ CRI 런타임에 작업 위임 │ │
│ └──────────────────┬──────────────────────────┘ │
│ │ │
│ ┌───────────┴───────────┐ │
│ ↓ ↓ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ kube-proxy │ │ CRI 런타임 │ │
│ │ ┌─────────┐ │ │ (containerd)│ │
│ │ │iptables │ │ │ │ │ │
│ │ │ /IPVS │ │ │ ↓ │ │
│ │ └─────────┘ │ │ ┌─────────┐ │ │
│ │ │ │ │ CNI │ │ │
│ │ 서비스 통신 │ │ │플러그인 │ │ │
│ │ 라우팅 담당 │ │ └─────────┘ │ │
│ └─────────────┘ │ │ │ │
│ │ │ ↓ │ │
│ │ │ ┌─────────┐ │ │
│ │ │ │ OCI │ │ │
│ │ │ │ 런타임 │ │ │
│ │ │ │ (runc) │ │ │
│ │ │ └─────────┘ │ │
│ │ └──────┬──────┘ │
│ │ │ │
│ └──────────┬──────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────┐ │
│ │ Pods (컨테이너들) │ │
│ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │
│ │ │Pod1 │ │Pod2 │ │Pod3 │ │Pod4 │ │ │
│ │ └─────┘ └─────┘ └─────┘ └─────┘ │ │
│ └─────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
노드 컴포넌트 요약:
노드 컴포넌트 핵심 정리:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[kubelet]
역할: 노드의 파드를 관리
├─ API 서버에서 파드 사양 수신
├─ 파드 상태 모니터링 및 보고
└─ CRI 런타임에 작업 위임
[kube-proxy]
역할: 서비스를 향한 통신을 해당 파드에 전달
├─ 서비스 통신 라우팅 담당
└─ 리눅스에서는 iptables/IPVS 기능 사용
[CRI 런타임] (containerd, CRI-O)
역할: kubelet 지시를 받아 파드/이미지 관리
├─ 규격: Container Runtime Interface (CRI)
├─ 통신: gRPC API
├─ 이미지 풀/관리
└─ 컨테이너 그룹을 파드로 관리
[CNI 플러그인] (Calico, Flannel, Cilium)
역할: 파드 네트워크 설정
├─ 파드에 네트워크 인터페이스 부여
├─ IP 주소 할당
└─ 파드 간 통신 경로 관리
사용: CRI 런타임에서 호출
[OCI 런타임] (runc, crun)
역할: 실제 컨테이너 생성 및 실행
├─ 규격: OCI Runtime Specification
├─ 호스트와 격리된 실행 환경 제공
└─ 네임스페이스, cgroups 등 설정
사용: CRI 런타임에서 호출
파드 생성 전체 흐름:
파드 생성 전체 과정:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[1] 사용자 → kubectl apply
↓
[2] kube-apiserver → 파드 정보 저장
↓
[3] kube-scheduler → 노드 선택
↓
[4] kubelet (선택된 노드)
│
│ CRI API (gRPC)
↓
[5] CRI 런타임 (containerd)
│
├─ [5a] 이미지 풀 (없으면 레지스트리에서 다운로드)
│
├─ [5b] 파드 샌드박스 생성
│ │
│ │ CNI 호출
│ ↓
│ [5b-1] CNI 플러그인
│ └─ IP 할당, 네트워크 설정
│
└─ [5c] 앱 컨테이너 생성
│
│ OCI Runtime Spec
↓
[5c-1] OCI 런타임 (runc)
└─ 컨테이너 프로세스 시작
↓
[6] 파드 실행 완료
│
│ 상태 보고
↓
[7] kubelet → kube-apiserver
(파드 상태 업데이트)
확인 명령어:
# 노드 컴포넌트 상태 확인
kubectl get nodes -o wide
# kubelet 상태 확인 (노드에서 실행)
systemctl status kubelet
# CRI 런타임 확인 (containerd 예시)
crictl info
crictl ps
# CNI 플러그인 확인
ls /etc/cni/net.d/
cat /etc/cni/net.d/*.conflist
# kube-proxy 모드 확인
kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode
# IPVS 규칙 확인 (IPVS 모드인 경우)
ipvsadm -Ln
# iptables 규칙 확인 (iptables 모드인 경우)
iptables -t nat -L KUBE-SERVICES -n
참고 자료
공식 문서:
- Cluster Networking: https://kubernetes.io/docs/concepts/cluster-administration/networking/
- Network Plugins: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/
- kube-proxy: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/
CNI 관련:
- CNI Specification: https://github.com/containernetworking/cni
- Calico: https://docs.projectcalico.org/
- Cilium: https://docs.cilium.io/
- Flannel: https://github.com/flannel-io/flannel